home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc617.txt < prev    next >
Text File  |  1994-08-01  |  8KB  |  220 lines
  1. Network Working Group                                   Edward Taft (PARC-MAXC)
  2. Request for Comments: 617                                              Feb 1974
  3. NIC #21771
  4.  
  5.  
  6.               A Note on Socket Number Assignment 2
  7.  
  8.  
  9. INTRODUCTION
  10.  
  11. In several current and proposed protocols, as well as in a few
  12. other documents, the assumption is made (or implied) that a user
  13. process in control of one end of a Telnet connection has free
  14. access to a group of socket numbers beginning with or surrounding
  15. the Telnet socket numbers.
  16.  
  17. For example, the File Transfer Protocol (RFC 542, NIC #17759)
  18. specifies that the default data transfer sockets are S+2, S+3,
  19. U+4, and U+5, where S and U are the server and user sockets
  20. involved in the initial connection (ICP).
  21.  
  22. Similarly, the proposed Network Graphics Protocol (NIC #19933)
  23. provides for a second connection pair for graphics data,
  24. parallel to the Telnet connection, using (at both ends) sockets
  25. n+6 and n+7, where n is the Telnet receive socket.
  26.  
  27. I would like to point out to designers of protocols that the
  28. Host-Host Protocol (NIC #8246) quite explicitly places no
  29. interpretations or constraints on host assignment of socket
  30. numbers, except for the use of the low-order bit to indicate
  31. direction of data flow. We should refrain from making further
  32. assumptions (as does the "Socket Number List" document (RFC 503,
  33. NIC #15747) in stating that the low-order 8 bits are
  34. "user-specified"), lest we inadvertently exclude certain host
  35. software architectures or protocol implementations.
  36.  
  37.  
  38. AN EXAMPLE
  39.  
  40. To illustrate the source of my concern, let me briefly describe
  41. the user software interface to the network in the PDP-10 NCP
  42. implementation currently in use at HARV-10, CMU-10A, and CMU-108.
  43. I will then show why the fixed socket number requirements of the
  44. two protocols I mentioned above present implementation
  45. difficulties, especially at the server end.
  46.  
  47. Opening a connection at one of these hosts causes the creation of
  48. a "device" (in approximately the same manner as, say, mounting a
  49. disk pack). As such, an open connection is subject to any one of
  50. a number of operations on devices in 10/50, including assignment
  51. of logical names, opening for data transfer, and reassignment to
  52. another job.
  53.  
  54.  
  55.  
  56.                                -1-
  57.  
  58.  
  59. The NCP allows a (non-privileged) user program to specify the
  60. low-order 8 bits of the socket number of any connection which it
  61. opens, and to specify that the other 24 bits be assigned in one of
  62. three ways:
  63.  
  64. -- As a function of the job number, making a "job-relative"
  65. socket.
  66.  
  67. -- As a function of the user identification, making a
  68. "user-relative" socket.
  69.  
  70. -- As a "guaranteed unique" number, i.e. one assigned by the
  71. NCP such that no other socket number in use has the same
  72. high-order 24 bits.
  73.  
  74. A program may also specify all 32 bits of a local socket number
  75. provided the high-order 24 bits are the same as the corresponding
  76. bits in some other socket already owned by the same job.
  77.  
  78. The NCP will, of course, allow assignment of a socket generated in
  79. any of the above ways only if it is not already in use by the same
  80. or any other job.
  81.  
  82.  
  83. PROBLEMS IN THE FTP SERVER IMPLEMENTATION 5
  84.  
  85. The FTP server is implemented in a manner that some readers may
  86. find reminiscent of Padlipsky's "Unified User Level Protocol" (RFC
  87. 451, NIC #14135). Rather than directly executing most FTP
  88. functions (in particular, system access and file transfer
  89. functions), it merely maps FTP commands into local commands which
  90. it "types" on a pseudo-Teletype (PTY) to a subjob, and similarly
  91. maps local responses into FTP responses.
  92.  
  93. This scheme makes maximum use of existing software and
  94. mechanisms for user authentication, accounting, and file
  95. access, and eliminates the need for the (privileged) FTP server
  96. to perform them interpretively. (This conforms to the
  97. "principle of least privilege" described in RFC 501, NIC
  98. #15818.)
  99.  
  100. In this implementation, FTP data transfers are performed by an
  101. entirely different process (with a different user identification)
  102. from the one that manages the server end of the Telnet connection.
  103. Hence, since server sockets S and S+1 belong to the server
  104. "control" job and sockets S+2 and S+3 are in the same 256-socket
  105. number range, the latter two sockets are inaccessible to the "data
  106. transfer" subjob.
  107.  
  108.  
  109.  
  110.  
  111.                                  -2-
  112.  
  113.  
  114. Those who attended last spring's FTP meeting may recall that I
  115. objected strenuously to the requirement that the FTP server use
  116. a fixed pair of data sockets relative to its Telnet sockets, as
  117. opposed to the old scheme in which the server has complete
  118. freedom in the choice of its data sockets. The principal
  119. reason is that it would seem to rule out the "two-process"
  120. scheme I have just described.
  121.  
  122. In fact, in our case there is a way around the problem. The
  123. FTP server control job can open the data connections itself,
  124. then "reassign" the created "device" to the data transfer
  125. subjob. A kludgey solution at best, and one I would rather
  126. have avoided! Inter-job socket reassignment is hardly an
  127. operation one is likely to find available in most operating
  128. systems.
  129.  
  130.  
  131. DIFFICULTIES WITH THE GRAPHICS PROTOCOL
  132.  
  133. Providing a graphics connection parallel (at a fixed socket number
  134. distance) to the Telnet connection might potentially present the
  135. same difficulty as described above for FTP connections.
  136.  
  137. In the most frequently used model of Telnet communication, as
  138. well as in many implementations, the server Telnet is a process
  139. quite distinct from the "user" process under its control. The
  140. two processes are typically interfaced through the operating
  141. system's terminal service in such a way that the "user" process
  142. perceives a ,terminal" as opposed to a "network connection".
  143.  
  144. In Tenex, for example, a job controlled from a network
  145. terminal has no handle whatever on the server Telnet
  146. connection; hence, it has no way of obtaining control of
  147. sockets n+6 and n+7 for a graphics connection.
  148.  
  149. In the Harvard-Carnegie 10/50 implementation, it happens (for
  150. largely accidental reasons) that a job logged in from the
  151. network does have control (i.e. is considered the owner) of the
  152. server Telnet sockets.
  153.  
  154. However, there is another problem. Many operating systems provide
  155. means by which the association between terminals and jobs may be
  156. changed.
  157.  
  158. To use familiar terminology, a terminal may be "detached" from
  159. one job and "attached" to another, in a manner which does not
  160. destroy any jobs or any network connections.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.                               -3-
  167.  
  168.  
  169.  
  170. Hence, it is entirely possible that a user could start up a
  171. program that uses sockets n+6 and n+7 (where n is the server
  172. Telnet receive socket), detach his terminal from that job, attach
  173. it to another, attempt to run a program using the Graphics
  174. Protocol, and have the attempted data connection fail because
  175. sockets n+6 and n+7 are already in use (for the same value of n,
  176. since we are referring to the same network terminal).
  177.  
  178.  
  179. CONCLUSION 7
  180.  
  181. There are, of course, a few network-wide socket number conventions
  182. necessary for establishing initial connection.
  183.  
  184. Reserving sockets 0-255 for standard ICP functions is an
  185. example of one such convention.
  186.  
  187. Additionally, I think that for the purpose of simplicity it is
  188. reasonable to expect any process to be able to gain control of
  189. a small block of "adjacent" sockets, such as an even-odd pair
  190. (as in ICP), if it asks for them at the same time.
  191.  
  192. However, as the foregoing examples have demonstrated, to impose
  193. further fixed socket number requirements is to risk the danger of
  194. making unwarranted assumptions about the nature of protocol
  195. implementations, the structure of user processes, etc., at
  196. individual hosts.
  197.  
  198. Once the initial Telnet connection is established, any other
  199. necessary connections should be established by negotiation over
  200. the Telnet connection (e.g. by messages of the form "Please
  201. connect to my socket xxxxxx", "OK, connecting via my socket
  202. yyyyyy"). There is absolutely no need for any protocol to specify
  203. fixed socket numbers, except for the purposes of the initial
  204. connection (ICP).
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.                                     -4-